This refactoring effort centralizes and standardizes header generation across the Files SDK and CLI, consolidating all header logic into a single utility class—ZosFilesHeaders—and replacing duplicate header creation code across multiple methods.

The new implementation leverages a unified headerMap to manage header generation functions, ensuring that headers like responseTimeout, etag, and others are applied consistently in all ZosFiles REST calls.

• Header Generation now:

  • Requires:
    • the request options
  • Optionally takes:
    • dataLength parameter to add a Content-Length header when needed.
    • ZosFilesContext enum that guides which Content-Type headers are applied for certain methods. These enum values include:
      • USS_MULTIPLE
        • Forces a general content-type header ("Content-Type": "application/json") when multiple USS files.
      • ZFS& LIST
        • No content-type headers are applied.
      • UPLOAD
        • Applies the content-type header ("X-IBM-Data-Type": encoding ). And will pass Content-Type: application/octet-stream for binary data.
      • DOWNLOAD
        • applies Content-Type header.
      • No context (default)
        • applies the default content-type header: {"X-IBM-Data-Type": "text"}

  ZosFilesHeaders.generateHeaders<T>({
    options,
    context,
    dataLength,
  }: {
    options: T;
    context?: ZosFilesContext;
    dataLength?: number | string;
  }): IHeaderContent[]

Because of this centralization, organization, and newly-provided, clear header expectations, any future header changes or additions require modifications in only one location. Creating headers can now be done with a single function call without much thought required in future development of the methods within ZosFiles SDK.